The advent of networked client devices (e.g., devices that are connected to a common network), such as Digital Living Network Alliance (DLNA) devices, within the home has created a mixture of different interfaces through which subscribers may consume multimedia. Once connected to a network, networked client devices can communicate and interact with each other, and networked client devices can be capable of providing a user interface that allows a user to cause a set-top box (STB) to tune to a specific channel according to a request from the user. In embodiments, networked client devices transmit a request to a STB by sending a uniform resource identifier (URI) (e.g., a character string identifying a specific web and/or network resource).
Customer premise equipment (CPE) devices such as gateway products provide Internet protocol (IP) Digital Living Network Alliance (DLNA) streaming of content to IP client STBs within a premise. The content can be live (linear) or recorded and may be designated by a uniform resource identifier (URI). The typical channel tuning by an IP client is achieved by doing a HTTP Get on a published URI by the gateway. Gateways as well as IP high-definition (HD) set top boxes (STB) can also stream content to standard retail IP clients (e.g., gaming devices, tablets, mobile devices, etc.) using DLNA. In general, STBs may be required to offer media transport with discovery and remote control pass through using open industry standards for home networking. For example, CPE devices such as HD STBs/gateways may be required to source content streams to networked devices using open standards (e.g., DLNA).
Typically, because of the wide variety of potential differences between client devices, many issues are encountered when attempting to implement DLNA streaming from CPE devices to one or more client devices. For example, where STB applications do not change or guide data is unavailable to the middleware, the STB platform has to offer the channel list, and because the platform has no knowledge of program information such as name and other guide data information, the STB provides a simple grouping of channels in a content directory service (CDS) directory folder containing channel identifiers grouped according to channel numbers (e.g., channel “number 1-100”, “number 100-200” till the end of channel list in a virtual channel number (VCN) list or other list of channel numbers listed sequentially in a single folder). Each folder typically contains a link to a channel number, which when requested by a client device, forces the STB to tune and start a HTTP streaming to that client device.
The current systems and methods utilized for the provisioning of channel information to client devices has created various issues. For one, the channel VCN list populated by the STB platform to a client device may have channels that are not authorized to the client (e.g., channels provided in high-definition format, pay-per view channels, channels that are not subscribed to by the client, channels blocked by security/parental settings, etc.). Thus, when a user tunes to the channel from the client device, the STB fails to tune to that channel and the user of the client device is not made aware of the reason for the channel tuning failure. As another example, the channel VCN list populated by the STB platform to a client device may include one or more invalid channels. Further, in some cases, the guide channel numbers also may be rearranged, thereby leading to tuning failures at the STB. As yet another example of an issue caused by the lack of guide information available for DLNA streaming, a client device may be precluded from tuning to a parentally locked channel (as STB platform is unaware of parental PINs). Because the STB platform likely is not aware of which channels are valid for a subscriber or user, the currently used method of listing all VCN entries leads to a poor user experience on client devices such as gaming devices, mobile phones, tablets, and others. For example, a user may become frustrated when having to scroll through the user interface of the client to reach a desired channel, especially when many of the listed channels (e.g., VCNs) are unavailable to the client device.
The lack of information may lead to other issues when determining whether content must be encrypted. For example, encryption is done if copy control information (CCI) value is more than zero. Without notifying client devices of the encryption status of channels, client devices which do not support digital transmission content protection (DTCP) may quit requesting content after first browsing the channel entries on a STB CDS. This eliminates several client devices from accessing a DLNA stream from a STB. Further, if a client device is DTCP-capable, the client device may anticipate that the content is DTCP encrypted, and thus begin a handshake with the STB even if the content is copy free. These behaviors are client implementation dependent. Because CCI rights of a channel are not made known prior to tuning to a channel, many retail clients which do not support DTCP, will not start streaming with a STB.
Therefore, a need exists for a STB solution wherein easy channel browsing is enabled, while also increasing client device coverage by denoting appropriate DTCP notation.
Like reference numbers and designations in the various drawings indicate like elements.